iT邦幫忙

2026 iThome 鐵人賽

DAY 3
0
Vibe Coding

重新認識Github Copilot (續)系列 第 3

Day03 - 在 GitHub Copilot 中實現 Context Engineering

  • 分享至 

  • xImage
  •  

https://ithelp.ithome.com.tw/upload/images/20260915/20103333WzUv2vdHG3.png
今天要來介紹 GitHub Copilot 裡面的 Context Engineering 到底怎麼實踐的~ 這題其實對很多人都很有用,尤其是平常已經在用 Copilot、卻常常覺得它「好像有幫忙,但又幫不太到位」的人。有時候不是模型不夠強,是你餵給它的上下文不夠剛好啊 😆

https://ithelp.ithome.com.tw/upload/images/20260915/20103333Xc5XQdn6cE.jpg

🧭 Prompt Engineering 跟 Context Engineering 差在哪?
一開始筆者先把這兩個觀念拆開講,因為很多人會把它們混在一起。 Prompt Engineering 比較像是你怎麼問、怎麼下指令;例如你叫 AI 扮演客服專員、語氣要有禮貌、不知道就誠實回答,這些都還是在「寫一段靜態指令」的範圍。

但 Context Engineering 不一樣,它重點不是「問得多漂亮」,而是「你提供了哪些相關資訊、工具跟資料」。 像同樣是客服場景,如果你順便把產品資訊、客戶歷史訂單、促銷內容一起丟進來,那它回答問題的能力就會完全不是同一個檔次。

📌 一句話記住
Prompt Engineering:重點在「怎麼問」。
Context Engineering:重點在「提供什麼資訊來讓它能回答」。

https://ithelp.ithome.com.tw/upload/images/20260915/20103333nSFKItMtQU.jpg
🎨 Andrej Karpathy: Context Engineering 很像一門藝術
大型語言模型像 CPU,token 像位元組,context window 很像記憶體。 那 Context Engineering 是什麼?就是在適當的時機,把適當的資訊塞進去,讓模型做出下一步最合理的事。

為什麼我把 Art 這個字特別圈起來?因為這件事情真的很吃經驗。 上下文不是越多越好,寫太少它亂猜,寫太多又把 context window 塞爆,甚至你整理上下文花的時間,居然比你自己下去寫程式還久,那不是很尷尬嗎 😅

筆者的實務心得:
上下文要給得剛剛好,這就是魔王關。
給太少,它瞎掰;給太多,它失焦;給得剛剛好,AI 才會像有練過一樣。
所以這件事才叫藝術。不是把所有資料一股腦灌進去就贏,而是要能切題、切量、切時機。

https://ithelp.ithome.com.tw/upload/images/20260915/20103333GWEG1sYbuc.jpg
📚 Context Engineering 的核心組成
筆者當時還翻了一篇整理得很不錯的論文,裡面講得很清楚: 傳統 Prompt 比較像一段固定字串,但 Context Engineering 是動態、結構化的組合。

它通常會由下面這些東西組起來:

📝 Instructions
你希望它遵守的規則、步驟、輸出格式。

📖 External Knowledge
像官方文件、Study Guide、考古題、內部知識庫這些外部資料。

🛠️ Tools
最常見就是 MCP Servers,讓 Copilot 能查資料、讀網頁、調 API。

🧠 Memory / State / Query
聊天記錄、當前狀態、使用者現在問的問題,這些都會影響最後答案。

這裡最重要的關鍵字其實就是 Dynamic。 也就是說,Context 不是一開始寫死就結束,它會跟著你目前打開的檔案、聊天歷史、工具查回來的資料、當前任務狀態一起變動。

論文裡面還把它拆成三塊:取得與生成、處理、管理。 實務上我們最能控制的,通常是第一塊,也就是「我要讓它去拿哪些資料」、「我要讓它可以叫哪些工具」。 至於管理那一塊,像長對話要不要壓縮、記憶要不要裁切,這就跟 context window 長度很有關。這也是為什麼每次看模型規格,除了聰不聰明,context window 多大也很重要啊。

https://ithelp.ithome.com.tw/upload/images/20260915/20103333rsbRC8xetf.jpg
🧩 GitHub Copilot 裡怎麼實現 Context Engineering?
接著筆者把焦點拉回 GitHub Copilot。它大致可以從三個方向來實現:

📂 In-memory Context
你目前打開的檔案、workspace、聊天歷史,這些都會成為 Copilot 的上下文來源,而且要善用@與#的Shortcut。

📄 Custom Chat Modes / Instructions
你可以在專案裡放 instruction 檔案,甚至拆成多個 Markdown 任務,讓它照步驟做,不要全部塞成一坨。

🔌 MCP Servers
這個超重要,等於幫 Copilot 裝外掛能力,讓它不只靠內建知識,還能查官方文件、抓網頁內容。

🛠️ 今天的實作目標:請 Copilot 幫筆者生 GH-300 模擬題,參考底下完整版影片

完整版影片
Yes

🏁 今日結論
GitHub Copilot 真正強的,不是你丟一句 Prompt 它會自動通靈,而是你能不能幫它把任務脈絡、資料來源、工具能力組起來。

MCP + GitHub Copilot Agent Mode 這組合,的確不錯用,以前都要到Microsoft Learning查資料,現在透過MCP,直接讓Copilot幫你查。 另外Playwright 也很實用,抓網頁內容、補外部脈絡甚至網頁自動化測試都很好用/images/emoticon/emoticon12.gif


上一篇
Day02 - 重新複習 Prompt Engineering for GitHub Copilot
系列文
重新認識Github Copilot (續)3
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言